Higher-Order Lucid∗

In this paper we remedy one of the most annoying weaknesses of Lucid and indexical languages in general: the lack of higher-order functions. We describe a simple generalization of the “place-code” approach (as discovered by Ostrum and formalized by Yaghi) which handles programs with functions of arbitrarily high orders; in other words, typed Iswim. A source program P with function definitions (including recursive ones) is translated into a 0-order program P ′ (one with no user-defined functions) with extra indexical operators for manipulating place codes. The only difference between the first-order and the general case is that in the general case we need more than one dimension of place codes. In fact, the number of dimensions is exactly the order of the program. The translated program P ′ can be implemented by eduction—tagged, demand-driven dataflow. The use of place codes causes no real complications: they are treated as just another field in the tag, along with the time and space tags. Naturally, the technique works even in the simple case that the original program has no indexical operators—is pure Iswim. In this case the technique gives us a promising new dataflow approach to implementing the typed lambda calculus. 1 The Need for Higher-Order Dataflow Indexical programmers have long felt that the lack of higher-order functions was one of Lucid’s greatest weaknesses—a weakness shared by all the indexical languages and, more generally, by most dataflow languages. This weakness was discussed in the Lucid Book where, for example, it was pointed out that we have to write comp(P ) = optimize(code(parse(lex (P )))) We cannot simply write lex | parse | code | optimize even though the latter reveals much better the dataflow structure (a simple pipeline) of the expression. The problem is that reverse function composition (the | operator) is second order—its arguments are (first-order) functions. A more serious instance of the problem arises in numerical analysis, one of the preferred application areas for dataflow. Many numerical algorithms (such as integration) naturally have a parameter which is a function (such as the function to be integrated). We cannot write a single Lucid function which performs integrations; instead we need a set of cloned function definitions, one for every particular function which needs (say) integrating. The problem is not really semantics: since the collection of Lucid streams forms a domain, we can in turn form domains of arbitrarily high-order functions over streams. There are some subtle ∗Presented to the 4th International Symposium on Lucid and Intensional Programming, SRI International, Menlo Park, Carlifornia, USA, 29–30 April 1991.